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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present document specifies the procedures and the SBc Application Part (SBc-AP) messages used on the SBc-AP 
interface between the Mobility Management Entity (MME) and the Cell Broadcast Centre (CBC). 

The present document supports the following functions. 

• Warning Message Transmission function in the EPS. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] IETF RFC 2460 (December 1998): "Internet Protocol, Version 6 (IPv6) Specification". 

[3] IETF RFC 791 (September 1981): "Internet Protocol". 

[4] IETF RFC 4960 (September 2007): "Stream Control Transmission Protocol" . 

[5] Void 

[6] Void 

[7] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); SI 

Application Protocol (SlAP)" 

[8] ITU-T Recommendation X.680 (07/2002): "Information Technology - Abstract Syntax Notation 

One (ASN.l): Specification of basic notation". 

[9] ITU-T Recommendation X.681 (07/2002): "Information Technology - Abstract Syntax Notation 

One (ASN.l): Information object specification". 

[10] ITU-T Recommendation X.691 (07/2002): "Information Technology - ASN.l encoding rules - 

Specification of Packed Encoding Rules (PER)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 
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Elementary Procedure: SBc-AP consists of Elementary Procedures (EPs). An Elementary Procedure is a unit of 
interaction between MME and CBC. These Elementary Procedures are defined separately and are intended to be used to 
build up complete sequences in a flexible manner. If the independence between some EPs is restricted, it is described 
under the relevant EP description. Unless otherwise stated by the restrictions, the EPs may be invoked independently of 
each other as stand alone procedures, which can be active in parallel. Examples on using several SBc-APs together with 
each other and EPs from other interfaces can be found in reference [FES]. 

An EP consists of an initiating message and possibly a response message. Two kinds of EPs are used: 

Class 1: Elementary Procedures with response (success and/or failure). 

Class 2: Elementary Procedures without response. 

For Class 1 EPs, the types of responses can be as follows: 

Successful: 

A signalling message explicitly indicates that the elementary procedure successfully completed with the 
receipt of the response. 

Unsuccessful: 

A signalling message explicitly indicates that the EP failed. 

On time supervision expiry (i.e. absence of expected response). 

Successful and Unsuccessful: 

One signalling message reports both successful and unsuccessful outcome for the different included requests. 
The response message used is the one defined for successful outcome. 

Class 2 EPs are considered always successful. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

<none> 

Editor" s note: To be completed or section removed. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

EPC Evolved Packet Core 

EPS Evolved Packet System 

ETWS Earthquake and Tsunami Warning System 



4 SBc description 

4.1 Transport 

4.1.1 General 

This subclause specifies the standards for signalling transport to be used across SBc-AP interface. SBc-AP interface is a 
logical interface between the MME and the CBC. All the SBc-AP messages described in the present document require 
an SCTP association between the MME and the CBC. 
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4.1.2 Network layer 



The MME and the CBC shall support IPv6 (see IETF RFC 2460 [2]) and/or IPv4 (see IETF RFC 791 [3]). 
The IP layer of SBc-AP only supports point-to-point transmission for delivering SBc-AP messages. 

4.1.3 Transport layer 

SCTP (see IETF RFC 4960 [4]) shall be supported as the transport layer of SBc-AP messages. 

Semi-permanent SCTP associations shall be established between MME and CBC, i.e. the SCTP associations shall 
remain up under normal circumstances. 

Local multi-homing should be supported. Remote multi-homing shall be supported. 

Multiple local SCTP endpoints may be supported. Multiple remote SCTP endpoints shall be supported. When multiple 
local or remote SCTP endpoints are configured, several simultaneous SCTP associations shall be supported between 
MME and CBC. 

Checksum calculation for SCTP shall be supported as specified in RFC 4960 [4]. 

The CBC shall establish the SCTP association. 

The registered port number for SBc-AP is 29168. 

The registered payload protocol identifier for SBc-AP is 0. 

4.1 .4 Services expected from signalling transport 

The signalling connection shall provide in-sequence delivery of SBc-AP messages. SBc-AP shall be notified if the 
signalling connection breaks. 



4.2. 



SBc-AP functions 



4.2.1 Function of SBc-AP 

SBc-AP has the following function: 

Warning Message Transmission function: 

This functionality provides the means to start and overwrite the broadcasting of warning message. 

4.3 SBc-AP procedure 

4.3.1 General 

This sub-clause describes the parameters and detailed behaviors of different procedures. 



4.3.2 



List of SBc-AP elementary procedure 



SBc-AP has the following EP defined as a class 1 procedure: 

Table 4.3.2-1 : Meaning of abbreviations used in SBc-AP messages 



Elementary 
Procedure 


Initiating Message 


Successful Outcome 


Unsuccessful Outcome 


Response message 


Response message 


Write-Replace 

Warning 

procedure 


WRITE-REPLACE 
WARNING REQUEST 


WRITE-REPLACE 
WARNING RESPONSE 
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4.3.3 



Warning Message Transmission procedure 



4.3.3.1 General 

The purpose ofWrite-Replace Warning procedure is to start, overwrite the broadcasting of warning message. 

4.3.3.2 Successful Operation 



MME 



CBC 



WRITE-REPLACE WARNING REQUEST 



WRITE-REPLACE WARNING RESPONSE 



Figure 4.3.3.2-1 : Write-Replace Warning procedure. Successful operation. 

The CBC initiates the procedure by sending a WRITE-REPLACE WARNING REQUEST message to the MME. 

Upon reception of WRITE-REPLACE WARNING REQUEST message, the MME shall forward the message towards 
the eNBs belonged to the tracking area as indicated in List ofTAIs IE. 

If none of List ofTALs IE or Warning Area List IE is present in WRITE-REPLACE WARNING REQUEST message, 
the MME shall forward the message towards all connected eNBs. 

The MME returns a WRITE-REPLACE WARNING RESPONSE to the CBC immediately after the reception of the 
WRITE-REPLACE WARNING REQUEST message without waiting responses from eNBs. 

MME sets the cause IE to "Message accepted" in the WRITE-REPLACE WARNING RESPONSE message. 



4.3.3.3 



Unsuccessful Operation 



MME 



CBC 



WRITE-REPLACE WARNING REQUEST 



WRITE-REPLACE WARNING RESPONSE 



Figure 4.3.3.3-1 : Write-Replace Warning procedure. Unsuccessful operation. 

The CBC initiates the procedure by sending a WRITE-REPLACE WARNING REQUEST message to the MME. 

If MME cannot process the received WRITE-REPLACE WARNING REQUEST message, the MME shall return a 
WRITE-REPLACE WARNING RESPONSE message towards the CBC and the MME shall not forward the message 
towards the eNBs belonged to the tracking area as indicated in List ofTALs IE. 

MME indicates a reason of failure in the cause IE. 
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4.3.4 Message functional definition and content 

4.3.4.1 Message contents 

4.3.4.1.1 Presence 

All information elements in the message descriptions below are marked mandatory, optional or conditional according to 

table 4.3.4.1.1-1. 

Table 4.3.4.1.1-1 : Meaning of abbreviations used in SBc-AP messages 



Abbreviation 


Meaning 


M 


lEs marked as Mandatory (M) shall always be included in the 
message. 





lEs marked as Optional (0) may or may not be included in the 
message. 


C 


lEs marked as Conditional (C) shall be included in a message only if 
the condition is satisfied. Otherwise the IE shall not be included. 



4.3.4.1.2 



Criticality 



Each Information Element or Group of Information Elements may have criticality information applied to it. 
Following cases are possible: 

Table 4.3.4.1.2-1 : Meaning of content within "Criticality" column 



Abbreviation 



Meaning 



No criticality information is applied explicitly. 



YES 



Criticality information is applied. This is usable only for non- 
repeatable lEs 



GLOBAL 



The IE and all its repetitions together have one common criticality 
information. This is usable only for repeatable lEs. 



information. This is usable only for repeatable lEs. 

Each repetition of the IE has its own criticality information. It is not 
allowed to assign different criticality values to the repetitions. This is 
usable only for repeatable lEs. 



EACH 



4.3.4.1.3 Range 

The Range column indicates the allowed number of copies of repetitive lEs/lE groups. 

4.3.4.1.4 Assigned Criticality 

This column provides the actual criticality information as defined in subclause 4.5.3.2, if applicable. 

4.3.4.2 Warning Message Transmission Messages 

4.3.4.2.1 WRITE-REPLACE WARNING REQUEST 

This message is sent by the CBC to request start and overwrite of an ETWS message broadcast. 

Direction: CBC -^ MME 
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Table 4.3.4.2.1-1 : WRITE-REPLACE WARNING REQUEST message contents 



IE/Group Name 


Presence 


Range 


IE type and 
reference 


Semantics 
description 


Criticality 


Assigned 
Criticality 


Message Type 


M 




4.3.4.3.1 




YES 


ignore 


Message Identifier 


M 




[7] 




YES 


reject 


Serial Number 


M 




[7] 




YES 


reject 


List of TAIs 











YES 


reject 


>TAI List Item 




1 to 
<maxnoofTAI> 










»TAI 


M 












Warning Area List 







[7] 




YES 


ignore 


Repetition Period 


M 




[7] 




YES 


reject 


Number of Broadcast 
Requested 


M 




[7] 




YES 


reject 


Warning Type 







[71 




YES 


ignore 


Warning Security 
Information 







[7] 




YES 


ignore 


Data Coding Scheme 







[7] 




YES 


ignore 


Warning Message 
Contents 







[7] 




YES 


ignore 



Table 4.3.4.2.1-2: RANGE explanation 



Range bound 


Explanation 


maxnooflAI 


Maximum no. of TAI subject for warning message broadcast. Value 
is 65535. 



4.3.4.2.2 WRITE-REPLACE WARNING RESPONSE 

This message is sent by the MME to acknowledge the CBC on the start or overwrite request of an ETWS message. 

Direction: CBC -^ MME 

Table 4.3.4.2.2-1 : WRITE-REPLACE WARNING RESPONSE message contents 



IE/Group Name 


Presence 


Range 


IE type and 
reference 


Semantics 
description 


Criticality 


Assigned 
Criticality 


Message Type 


M 




4.3.4.3.1 




YES 


ignore 


Message Identifier 


M 




[7] 




YES 


reject 


Serial Number 


M 




[71 




YES 


reject 


Cause 


M 




4.3.4.3.2 




YES 


ignore 


Criticality Diagnostics 







4.3.4.3.3 




YES 


ignore 



4.3.4.3 



Information element definition 



4.3.4.3.1 Message Type 

The Message Type IE uniquely identifies the message being sent. It is mandatory for all messages 
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Table 4.3.4.3.1-1 : Message Type information element 



IE/Group Name 


Presence 


Range 


IE type and reference 


Semantics description 


Message Type 








Assumed max no of messages 
is 256. 


>Procedure Code 


M 




(Write-Replace 
Warning, ...) 




>Type of Message 


M 




CHOICE 

(Initiating IVIessage, 
Successful Outcome, 
Unsuccessful Outcome, 





4.3.4.3.2 Cause 

The purpose of the Cause IE is to indicate the reason for a particular event for the SBc-AP protocol. 

Table 4.3.4.3.2-1 : Cause information element 



IE/Group Name 


Presence 


Range 


IE Type and Reference 


Semantics 
Description 


Cause 


M 




INTEGER (Message accepted. 
Parameter not recognised. Parameter 
value invalid. Valid message not 
identified. Tracking area not valid. 
Unrecognised message. Missing 
mandatory element, MME capacity 
exceeded, MME memory exceeded, 
Warning broadcast not supported, 
Warning broadcast not operational. 
Message reference already used. 
Unspecified error, Transfer syntax 
error. Semantic error. Message not 
compatible with receiver state. 
Abstract syntax error reject. Abstract 
syntax error ignore and notify, 
Abstract syntax error falsely 
constructed message, ...) 





4.3.4.3.3 



Criticality Diagnostics 



The Criticality Diagnostics IE is sent by the MME when parts of a received message have not been comprehended or 
were missing, or if the message contained logical errors. When applicable, it contains information about which lEs were 
not comprehended or were missing. 
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Table 4.3.4.3.3-1 : Criticality Diagnostics information element 



IE/Group Name 


Presence 


Range 


IE type and 
reference 


Semantics description 


Procedure Code 







INTEGER 
(0..255) 


Procedure Code is to be used if 
Criticality Diagnostics is part of 
Error Indication procedure, and 
not within the response 
message of the same procedure 
that caused the error 


Triggering Message 







ENUMERATED! 

initiating 

message, 

successful 

outcome, 

unsuccessful 

outcome, 

outcome) 


The Triggering Message is used 
only if the Criticality Diagnostics 
is part of Error Indication 
procedure. 


Procedure Criticality 







ENUMERATED! 
reject, ignore, 
notify) 


This Procedure Criticality is 
used for reporting the Criticality 
of the Triggering message 
(Procedure). 


Information Element 
Criticality Diagnostics 




to <maxnoof 
errors> 






>IE Criticality 


M 




ENUMERATED! 
reject, ignore, 
notify) 


The IE Criticality is used for 
reporting the criticality of the 
triggering IE. The value 'ignore' 
shall not be used. 


>IEID 


M 




INTEGER 
(0.. 65535) 


The IE ID of the not understood 
or missing IE 












>Type of Error 


M 




ENUMERATED! 

not understood, 

missing, ...) 





Table 4.3.4.3.3-2: RANGE explanation 



Range bound 


Explanation 


maxnooferrors 


Maximum no. of IE errors allowed to be reported with a single 
message. The value for maxnooferrors is 256. 



4.4 



Message and information element abstract syntax 



4.4.1 General 

SBC-AP ASN.l definition conforms with [8] and [9]. 

The ASN.l definition specifies the structure and content of SBC-AP messages. SBC-AP messages can contain any lEs 
specified in the object set definitions for that message without the order or number of occurrence being restricted by 
ASN.l. However, for this version of the standard, a sending entity shall construct a SBC-AP message according to the 
PDU definitions module and with the following additional rules (Note that in the following IE means an IE in the object 
set with an explicit id. If one IE needed to appear more than once in one object set, then the different occurrences have 
different IE ids): 

lEs shall be ordered (in an IE container) in the order they appear in object set definitions. 

Object set definitions specify how many times lEs may appear. An IE shall appear exactly once if the presence 
field in an object has value "mandatory". An IE may appear at most once if the presence field in an object has 
value "optional" or "conditional". If in a tabular format there is multiplicity specified for an IE (i.e. an IE list) 
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then in the corresponding ASN.l definition the list definition is separated into two parts. The first part defines an 
IE container list where the list elements reside. The second part defines list elements. The IE container list 
appears as an IE of its own. For this version of the standard an IE container list may contain only one kind of list 
elements. 

If a SBC-AP message that is not constructed as defined above is received, this shall be considered as Abstract Syntax 
Error, and the message shall be handled as defined for Abstract Syntax error in subclause 4.5.3.6. 

4.4.2 Usage of protocol extension mechanism for non-standard use 

The protocol extension mechanism for non-standard use may be used: 

for special operator- (and/or vendor) specific features considered not to be part of the basic functionality, i.e. the 
functionality required for a complete and high-quality specification in order to guarantee multivendor 
interoperability. 

by vendors for research purposes, e.g. to implement and evaluate new algorithms/features before such features 
are proposed for standardisation. 

The extension mechanism shall not be used for basic functionality. Such functionality shall be standardised. 

4.4.3 Elementary procedure definitions 



************************************************************** 

-- Elementary Procedure definitions 

************************************************************** 

SBC-AP-PDU-Descriptions { 

itu-t (0) identif ied-organization (4) etsi (0) mobileDomain (0) 

eps-Access (21) modules (3) sbc-AP (3) versionl (1) sbc-AP-PDU-Descriptions (0) 

DEFINITIONS AUTOMATIC TAGS ::= 



************************************************************** 

-- IE parameter types from other modules. 

************************************************************** 

IMPORTS 

Criticality, 

ProcedureCode 
FROM SBC-AP-CommonDataTypes 

Write-Replace-Warning-Request , 
Write -Replace-Warning-Response 
FROM SBC-AP-PDU-Contents 

id-Write -Replace -Warning 
FROM SBC-AP-Constants; 

************************************************************** 

-- Interface Elementary Procedure Class 

************************************************************** 

SBC-AP-ELEMENTARY-PROCEDURE ::= CLASS { 
StlnitiatingMessage , 

StSuccessfulOutcome OPTIONAL, 

StUnsuccessfulOutcome OPTIONAL, 

StprocedureCode ProcedureCode UNIQUE, 

Stcriticality Criticality DEFAULT ignore 

} 

WITH SYNTAX { 

INITIATING MESSAGE ScInitiatingMessage 

[SUCCESSFUL OUTCOME ScSuccessf ulOutcome] 

[UNSUCCESSFUL OUTCOME &Unsuccessf ulOutcome] 
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PROCEDURE CODE ScprocedureCode 

[CRITICALITY &criticality] 

} 

************************************************************** 

-- Interface PDU Definition 

************************************************************** 

SBC-AP-PDU ::= CHOICE { 

initiatingMessage InitiatingMessage , 
successf ulOutcome Successf ulOutcome , 
unsuccessfulOutcome Unsuccessf ulOutcome, 



InitiatingMessage ::= SEQUENCE { 

procedureCode SBC-AP- ELEMENTARY- PROCEDURE . &procedureCode { {SBC-AP-ELEMENTARY- PROCEDURES } ) 
criticality SBC-AP-ELEMENTARY-PROCEDURE . &criticality { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) , 

value SBC-AP-ELEMENTARY-PROCEDURE.&InitiatingMessage { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) 

} 

Successf ulOutcome ::= SEQUENCE { 

procedureCode SBC-AP- ELEMENTARY- PROCEDURE . ^procedureCode {{ SBC-AP-ELEMENTARY- PROCEDURES } ) 
criticality SBC-AP-ELEMENTARY-PROCEDURE . &criticality { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) , 

value SBC-AP-ELEMENTARY-PROCEDURE.&Successf ulOutcome { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) 

} 

UnsuccessfulOutcome ::= SEQUENCE { 

procedureCode SBC-AP- ELEMENTARY- PROCEDURE . ^procedureCode {{ SBC-AP-ELEMENTARY- PROCEDURES } ) 
criticality SBC-AP-ELEMENTARY-PROCEDURE . ^criticality { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) , 

value SBC-AP-ELEMENTARY-PROCEDURE.&UnsuccessfulOutcome { {SBC-AP-ELEMENTARY- 

PROCEDURES} {©procedureCode} ) 

} 

************************************************************** 

-- Interface Elementary Procedure List 

************************************************************** 

SBC-AP-ELEMENTARY-PROCEDURES SBC-AP-ELEMENTARY-PROCEDURE ::= { 
SBC-AP - ELEMENTARY- PROCEDURES - CLASS - 1 | 
SBC-AP - ELEMENTARY- PROCEDURES - CLASS - 2 

} 

SBC-AP-ELEMENTARY-PROCEDURES-CLASS-1 SBC-AP-ELEMENTARY-PROCEDURE ::= { 
write-Replace-Warning , 



SBC-AP- ELEMENTARY- PROCEDURES -CLASS -2 SBC-AP-ELEMENTARY-PROCEDURE 

} 

write-Replace-Warning SBC-AP-ELEMENTARY-PROCEDURE ::= { 
INITIATING MESSAGE Write-Replace-Warning-Request 
SUCCESSFUL OUTCOME Write-Replace-Warning-Response 

PROCEDURE CODE id-Write-Replace-Warning 
CRITICALITY reject 

} 

END 



4.4.4 PDU definitions 



************************************************************** 



PDU definitions for SBC-AP. 
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************************************************************** 

SBC-AP-PDU-Contents { 

itu-t (0) identif ied-organization (4) etsi (0) mobileDomain (0) 

eps-Access (21) modules (3) sbc-AP (3) versionl (1) sbc-AP-PDU-Contents (1) 

DEFINITIONS AUTOMATIC TAGS :: = 

BEGIN 

************************************************************** 

-- IE parameter types from other modules. 

************************************************************** 

IMPORTS 

Cause, 

Criticality-Diagnostics , 
Data -Coding- Scheme, 
Message -Identifier, 
Serial -Number, 
List-of-TAIs, 
Warning-Area-List , 
Repetition- Period, 
Number-of -Broadcasts -Requested, 
Warning-Type , 

Warning- Security- Information, 
Warning-Message -Content 
FROM SBC-AP- lEs 

ProtocolExtensionContainer{ } , 
ProtocolIE-Container{ } , 
SBC-AP - PROTOCOL - EXTENS ION , 
SBC-AP - PROTOCOL - I ES 
FROM SBC-AP-Containers 

id- Criticality-Diagnostics, 
id-Cause, 

id- Data -Coding- Scheme, 
id-List -of -TAIs, 
id-Message -Identifier, 
id- Serial -Number, 

id-Number-of -Broadcasts -Requested, 
id-Radio-Resource-Loading-List , 
id- Recovery- Indication, 
id- Repetition- Period, 
id-Warning-Area-List , 
id-Warning-Message-Content , 
id- Warning- Security- Information, 
id- Warning- Type 
FROM SBC-AP-Constants; 

************************************************************** 



Write-Replace -Warning-Request 



************************************************************** 



Write-Replace-Warning-Request ::= SEQUENCE { 

protocolIEs ProtocolIE-Container { {Write-Replace-Warning-Request-IEs} }, 

protocolExtensions ProtocolExtensionContainer { {Write-Replace-Warning-Request-Extensions} 

} OPTIONAL, 



Write-Replace-Warning-Request-IEs SBC-AP-PROTOCOL-IES ::= { 

{ ID id-Message-Identifier CRITICALITY reject TYPE Message-Identifier PRESENCE mandatory 

I 

{ ID id-Serial-Number CRITICALITY reject TYPE Serial-Number PRESENCE mandatory } | 

{ ID id-List-of-TAIs CRITICALITY reject TYPE List-of-TAIs PRESENCE optional } | 

{ ID id-Warning-Area-List CRITICALITY ignore TYPE Warning-Area-List PRESENCE optional } 

I 

{ ID id-Repetition- Period CRITICALITY reject TYPE Repetition- Period PRESENCE mandatory 

} I 

{ ID id-Number-of -Broadcasts-Requested 
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CRITICALITY reject TYPE Number-of -Broadcasts-Requested PRESENCE mandatory } | 
{ ID id-Warning-Type CRITICALITY ignore TYPE Warning-Type PRESENCE optional } | 
{ ID id-Warning-Security-Information CRITICALITY ignore TYPE Warning-Security- 
Information PRESENCE optional } | 

{ ID id-Data-Coding-Scheme CRITICALITY ignore TYPE Data-Coding-Scheme PRESENCE optional } 

I 

{ ID id-Warning-Message-Content 

CRITICALITY ignore TYPE Warning-Message-Content PRESENCE optional } , 



Write-Replace-Warning-Request- Extensions SBC-AP- PROTOCOL- EXTENSION 



************************************************************** 

- - Write-Replace-Warning-Response 

************************************************************** 

Write-Replace-Warning-Response ::= SEQUENCE { 

protocolIEs ProtocolIE-Container { {Write-Replace-Warning-Response-IEs} }, 

protocolExtensions ProtocolExtensionContainer { {Write-Replace-Warning-Response-Extensions} 

} OPTIONAL, 



Write-Replace-Warning-Response-IEs SBC-AP-PROTOCOL-IES ::= { 

{ ID id-Message-Identifier CRITICALITY reject TYPE Message-Identifier PRESENCE mandatory } 

I 

{ ID id-Serial-Number CRITICALITY reject TYPE Serial-Number PRESENCE mandatory } | 

{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory } 

I 

{ ID id-Criticality-Diagnostics CRITICALITY ignore TYPE Criticality-Diagnostics PRESENCE 
optional } , 

} 

Write-Replace-Warning-Response-Extensions SBC-AP-PROTOCOL-EXTENSION ::= { 



END 



4.4.5 Information element definitions 



************************************************************** 

Information Element Definitions 
************************************************************** 



SBC-AP-IEs { 

itu-t (0) identif ied-organization (4) etsi (0) mobileDomain (0) 

eps-Access (21) modules (3) sbc-AP (3) versionl (1) sbc-AP-IEs (2) 

DEFINITIONS AUTOMATIC TAGS ::= 

BEGIN 

IMPORTS 

maxNrOf Errors , 

maxNrOfTAIs, 

maxnoof TAI f orWarning , 

maxnoof CelllD, 

maxnoof EmergencyArealD , 

id- TypeOf Error 

FROM SBC-AP-Constants 

Criticality, 
ProcedureCode , 
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TriggeringMessage, 
ProtocolIE-ID 
FROM SBC-AP-CommonDataTypes 

ProtocolExtensionContainer{ 

SBC - AP - PROTOCOL - EXTENS ION 
FROM SBC-AP-Containers; 



-- C 



Cause : : = INTEGER { 

message-accepted (0) 

parameter-not-recognised (1) 

parameter-value- invalid (2) 

valid-message-not-identified (3) 

tracking-area-not-valid (4) 

unrecognised-message (5) 

missing-mandatory-element (6) 

mME-capacity-exceeded (7) 

mME-memory-exceeded (8) 

warning- broadcast -not -supported (9) 

warning- broadcast -not -operational (10 

message -reference -already- used {11 

unspecif ed-error (12 

transfer-syntax-error {13 

semantic-error {14 

message -not -compatible -with- receiver- St ate {15 

abstract-syntax-error-reject {16 

abstract -syntax- error- ignore- and-not if y {17 
abs t rac t -syntax- error- falsely- const ructed-mes sage {18 

} {0..255) 



Cellldentity 



BIT STRING {SIZE {28)) 



Criticality- Diagnostics 
procedureCode 
triggeringMessage 
procedureCriticality 



: : = SEQUENCE { 
ProcedureCode 
TriggeringMessage 

Criticality 



OPTIONAL, 
OPTIONAL, 
OPTIONAL, 



lEsCriticalityDiagnostics CriticalityDiagnostics- IE-List OPTIONAL, 
iE-Extensions ProtocolExtensionContainer { {CriticalityDiagnostics-ExtlEs} 



OPTIONAL, 



CriticalityDiagnostics- Ext lEs SBC-AP- PROTOCOL- EXTENSION 



CriticalityDiagnostics -IE-List 
SEQUENCE { 

lECriticality 

lE-ID 

typeOf Error 

iE-Extensions 
OPTIONAL, 



SEQUENCE {SIZE { 1 .. maxNrOf Errors ) ) OF 



Criticality, 
ProtocolIE-ID, 

TypeOf Error, 

ProtocolExtensionContainer 



{CriticalityDiagnostics -IE- Item- Ext lEs} } 



} 

CriticalityDiagnostics -IE- Item- Ext lEs SBC-AP- PROTOCOL- EXTENSION 



-- D 

Data -Coding- Scheme 

-- E 

ECGIList 



BIT STRING {SIZE {8) ) 



SEQUENCE {SIZE{1. .maxnoofCelllD) ) OF EUTRAN-CGI 
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Emergency-Area- ID-List ::= SEQUENCE {SIZE {1 . .maxnoof EmerArealDs) ) OF Emergency-Area- ID 

Emergency-Area- ID ::= OCTET STRING {SIZE {3)) 

EUTRAN-CGI ::= SEQUENCE { 

pLMNidentity PLMNidentity, 

cell-ID Cellldentity, 

IE-Extensions ProtocolExtensionContainer { {EUTRAN-CGI-ExtlEs} } OPTIONAL, 

} 

EUTRAN-CGI-ExtlEs SBC-AP-PROTOCOL-EXTENSION ::= { 



-- F 
-- G 
-- H 
-- I 
-- J 
-- K 
-- L 

List-of-TAIs ::= SEQUENCE {SIZE { 1 . . maxNrOf TAIs ) ) OF 

SEQUENCE { 

tai TAI 

} 

-- M 

Message-Identifier ::= BIT STRING {SIZE {16)) 

-- N 

Number-of-Broadcasts-Requested ::= INTEGER {1.. 65535) 

-- 

-- P 

PLMNidentity ::= TBCD-STRING 

-- Q 
-- R 

Repetition-Period ::= INTEGER {0..4096) 

-- 1 to 4096: Each unit represents a repetition of one second to a maximum of 

-- once per 4096 seconds {~1 hour) . 

-- 0: no repetition 

-- S 

Serial-Number ::= BIT STRING {SIZE {16)) 

-- T 

TAG ::= OCTET STRING {SIZE {2)) 

TAI-List-for-Warning ::= SEQUENCE {SIZE{1.. maxnoofTAIforWarning) ) OF TAI 

TAI : : = SEQUENCE { 

pLMNidentity PLMNidentity, 

t AC TAG , 

iE-Extensions ProtocolExtensionContainer { {TAI-ExtlEs} } OPTIONAL 

} 

TAI-ExtlEs SBC-AP-PROTOCOL-EXTENSION ::= { 

} 

TBCD-STRING ::= OCTET STRING {SIZE {3)) 
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TypeOf Error : : = ENUMERATED 
not -under stood, 
missing, 



-- U 
-- V 



-- W 

Warning-Area-List ::= CHOICE { 

cell-ID-List ECGIList, 

tracking-Area-List -for-Warning TAI-List-for-Warning 

emergency-Area- ID-List Emergency-Area- ID-List 



Warning-Message-Content ::= OCTET STRING {SIZE {1..9600)) 

Warning-Security-Information ::= OCTET STRING {SIZE {50)) 
Warning-Type ::= OCTET STRING {SIZE {2)) 

-- X 

-- Y 



4.4.6 Common definitions 

************************************************************** 

-- Common definitions 

************************************************************** 

SBC-AP-CommonDataTypes { 

itu-t {0) identif ied-organization {4) etsi {0) mobileDomain {0) 

eps-Access {21) modules {3) sbc-AP {3) versionl {1) sbc-AP-CommonDataTypes {3) 

DEFINITIONS AUTOMATIC TAGS ::= 

BEGIN 

Criticality ::= ENUMERATED { reject, ignore, notify } 

Presence ::= ENUMERATED { optional, conditional, mandatory } 

ProcedureCode ::= INTEGER {0..255) 

ProtocolExtensionID ::= INTEGER {0.. 65535) 

ProtocolIE-ID ::= INTEGER {0.. 65535) 



TriggeringMessage 
outcome, outcome} 

END 



ENUMERATED { initiating-message , successful-outcome, unsuccessful- 



4.4.7 Constant definitions 



************************************************************** 

-- Constant definitions 

************************************************************** 

SBC-AP-Constants { 

itu-t (0) identif ied-organization {4) etsi {0) mobileDomain {0) 

eps-Access {21) modules {3) sbc-AP {3) versionl {1) sbc-AP-Constants {4) 

DEFINITIONS AUTOMATIC TAGS :: = 
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BEGIN 



************************************************************** 



Elementary Procedures 



************************************************************** 



id-Write-Replace-Warning INTEGER ::= 



************************************************************** 



************************************************************** 

id-Broadcast-Message-Content INTEGER ::= 
id-Cause INTEGER ::= 1 

id-Criticality-Diagnostics INTEGER : : =2 
id-Data-Coding-Scheme INTEGER ::= 3 

id-Failure-List INTEGER ::= 4 

id-Message-Identifier INTEGER ::= 5 

id-Number-of-Broadcasts-Completed-List INTEGER ::= 6 
id-Number-of -Broadcasts-Requested INTEGER ::= 7 
id-Radio-Resource-Loading-List INTEGER ::= 8 
id-Recovery- Indication INTEGER ::= 9 

id-Repetition-Period INTEGER ::= 10 

id-Serial-Number INTEGER : : = 11 

id- Service -Areas -Li St 
id- TypeOf Error 
id-List -of -TAIs 
id- Warning- Area -Li St 
id- Warning-Message -Content 

id-Warning-Security-Information INTEGER ::= 17 
id-Warning-Type INTEGER ::= 18 



************************************************************** 

Extension constants 

************************************************************** 

************************************************************** 



INTEGER : 


= 12 


INTEGER : 


= 13 


INTEGER : 


= 14 


INTEGER : 


= 15 


INTEGER : 


= 16 



Lists 



************************************************************** 



maxNrOfErrors INTEGER 

maxnoofCelllD INTEGER 

maxNrOfTAIs INTEGER 

maxnoofgencyEmerArealD INTEGER 

maxnoofTAIforWarning INTEGER 



256 

65535 

65535 

65535 

65535 



maxProtocolExtensions INTEGER ::= 65535 

maxProtocolIEs INTEGER ::= 65535 

END 

4.4.8 Container Definitions 

************************************************************** 

-- Container definitions 

************************************************************** 

SBC-AP-Containers { 

itu-t (0) identif ied-organization (4) etsi (0) mobileDomain (0) 

eps-Access (21) modules (3) sbc-AP (3) versionl (1) sbc-AP-Containers (5) 

DEFINITIONS AUTOMATIC TAGS ::= 

BEGIN 
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************************************************************** 

-- IE parameter types from other modules. 

************************************************************** 

IMPORTS 

Criticality, 

Presence, 

ProtocolExtensionID, 

ProtocolIE-ID 
FROM SBC-AP-CommonDataTypes 

maxProtocolExtensions , 
maxProtocolIEs 
FROM SBC-AP-Constants; 

************************************************************** 

-- Class Definition for Protocol lEs 

************************************************************** 

SBC -AP- PROTOCOL- I ES ::= CLASS { 

&id ProtocolIE-ID UNIQUE, 

Stcriticality Criticality DEFAULT ignore, 

StValue , 
Scpresence Presence 

} 

WITH SYNTAX { 

ID Stid 

CRITICALITY ^criticality 

TYPE ScValue 

PRESENCE ^presence 

} 

************************************************************** 

-- Class Definition for Protocol Extensions 

************************************************************** 

SBC-AP-PROTOCOL-EXTENSION ::= CLASS { 

Stid ProtocolExtensionID UNIQUE, 

Stcriticality Criticality DEFAULT ignore, 

StExtension, 

^presence Presence 

} 

WITH SYNTAX { 

ID Slid 

CRITICALITY ScCriticality 

EXTENSION StExtension 

PRESENCE ^presence 

} 

************************************************************** 



-- Container for Protocol lEs 

************************************************************** 

ProtocolIE-Container {SBC-AP- PROTOCOL- lES : lEsSetParam} ::= 
SEQUENCE (SIZE { .. maxProtocolIEs ) ) OF 
ProtocolIE-Field { {lEsSetParam} } 

ProtocolIE-Field { SBC-AP- PROTOCOL- lES : lEsSetParam} ::= SEQUENCE { 

id SBC-AP- PROTOCOL- lES.&id {{lEsSetParam}), 

criticality SBC-AP- PROTOCOL- lES . ^criticality { {lEsSetParam} {oid} ) 

value SBC-AP- PROTOCOL- lES.&Value ({ lEsSetParam} {oid} ) 

} 

********************************************** 

- - Container Lists for Protocol IE Containers 

************************************************************** 
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ProtocolIE-ContainerList {INTEGER : lowerBound, INTEGER : upperBound, SBC-AP-PROTOCOL-IES : 
lEsSetParam} : : = 

SEQUENCE {SIZE { lowerBound .. upperBound) ) OF 

ProtocolIE-Container { {lEsSetParam} } 

************************************************************** 

-- Container for Protocol Extensions 

************************************************************** 

ProtocolExtensionContainer {SBC-AP-PROTOCOL-EXTENSION : ExtensionSetParam} ::= 
SEQUENCE {SIZE { 1 . . maxProtocolExtensions ) ) OF 
ProtocolExtensionField { {ExtensionSetParam} } 

ProtocolExtensionField {SBC-AP-PROTOCOL-EXTENSION : ExtensionSetParam} ::= SEQUENCE { 
id SBC-AP-PROTOCOL-EXTENSION. &id {{ExtensionSetParam}), 

criticality SBC-AP-PROTOCOL-EXTENSION. &criticality { {ExtensionSetParam} {oid} ) , 
extensionValue SBC-AP-PROTOCOL-EXTENSION. StExtension { {ExtensionSetParam} {oid} ) 

} 
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4.4.9 Message sransfer syntax 



SBC-AP shall use the ASN.l Basic Packed Encoding Rules (BASIC-PER) Aligned Variant as transfer syntax as 
specified in ref. [10]. 

4.5 Handling of unknown, unforeseen or erroneous protocol 
data 

4.5.1 General 

Protocol Error cases can be divided into three classes: 

• Transfer Syntax Error; 

• Abstract Syntax Error; 

• Logical Error. 

Protocol errors can occur in the following functions within a receiving node: 



SBc-AP 

functional 

entity 



ASN.l Decoding 



> 



Logical Errors 
Abstract Syntax Errors 



Transfer Syntax Errors 



Figure 4.5.1-1 : Protocol Errors in SBc-AP 

The information stated in subclauses 4.5.2, 4.5.3 and 4.5.4, to be included in the message used when reporting an error, 
is what at minimum shall be included. Other optional information elements within the message may also be included, if 
available. This is also valid for the case when the reporting is done with a response message. 



4.5.2 Transfer Syntax Error 



A Transfer Syntax Error occurs when the receiver is not able to decode the received physical message Transfer syntax 
errors are always detected in the process of ASN. 1 decoding. If a Transfer Syntax Error occurs, the receiver should 
initiate Error Indication procedure with appropriate cause value for the Transfer Syntax protocol error. 

4.5.3 Abstract Syntax Error 
4.5.3.1 General 

An Abstract Syntax Error occurs when the receiving functional SBc-AP entity: 

1. receives lEs or IE groups that cannot be understood (unknown IE id); 

2. receives lEs for which the logical range is violated (e.g.: ASN.l definition: to 15, the logical range is to 10 
(values 1 1 to 15 are undefined), and 12 will be received; this case will be handled as an abstract syntax error 
using criticality information sent by the originator of the message); 
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3. does not receive lEs or IE groups but according to the specified presence of the concerning object, the IBs or IE 
groups should have been present in the received message; 

4. receives IBs or IE groups that are defined to be part of that message in wrong order or with too many 
occurrences of the same IE or IE group; 

5. receives lEs or IE groups but according to the conditional presence of the concerning object and the specified 
condition, the lEs or IE groups should not have been present in the received message. 

Cases 1 and 2 (not comprehended IE/IE group) are handled based on received Criticality information. Case 3 (missing 
IE/IE group) is handled based on Criticality information and Presence information for the missing IE/IE group specified 
in the version of the specification used by the receiver. Case 4 (lEs or IE groups in wrong order or with too many 
occurrences) and Case 5 (erroneously present conditional lEs or IE groups) result in rejecting the procedure. 

If an Abstract Syntax Error occurs, the receiver shall read the remaining message and shall then for each detected 
Abstract Syntax Error act according to the Criticality Information and Presence Information for the IE/IE group due to 
which Abstract Syntax Error occurred in accordance with subclauses 4.5.3.4 and 4.5.3.5. The handling of cases 4 and 5 
is specified in subclause 4.5.3.6. 

4.5.3.2 Criticality information 

In the SBc-AP messages there is criticality information set for individual lEs and/or IE groups. This criticality 
information instructs the receiver how to act when receiving an IE or an IE group that is not comprehended i.e. the 
entire item (IE or IE group) which is not (fully or partially) comprehended shall be treated in accordance with its own 
criticality information as specified in subclause 4.5.3.4. 

In addition, the criticality information is used in case of the missing IE/IE group abstract syntax error (see subclause 
4.5.3.5). 

The receiving node shall take different actions depending on the value of the Criticality Information. The three possible 
values of the Criticality Information for an IE/IE group are: 

Reject IE; 

Ignore IE and Notify Sender; 

Ignore IE. 

The following rules restrict when a receiving entity may consider an IE, an IE group or an EP not comprehended (not 
implemented), and when action based on criticality information is applicable: 

1 . IE or IE group: When one new or modified IE or IE group is implemented for one EP from a standard version, 
then other new or modified lEs or IE groups specified for that EP in that standard version shall be considered 
comprehended by the receiving entity (some may still remain unsupported). 

2. EP: The comprehension of different EPs within a standard version or between different standard versions is not 
mandated. Any EP that is not supported may be considered not comprehended, even if another EP from that 
standard version is comprehended, and action based on criticality shall be applied. 

4.5.3.3 Presence information 

For many lEs/IE groups which are optional according to the ASN.l transfer syntax, SBc-AP specifies separately if the 
presence of these lEs/IE groups is optional or mandatory with respect to MME/CBC application. 

The presence field of the indicated classes supports three values: 

1 . Optional; 

2. Conditional; 

3. Mandatory. 
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If an IE/IE group is not included in a received message and the presence of the IE/IE group is mandatory or the 
presence is conditional and the condition is true according to the version of the specification used by the receiver, an 
abstract syntax error occurs due to a missing IE/IE group. 

4.5.3.4 Not comprehended IE/IE group 

4.5.3.4.1 Procedure code 

The receiving node shall treat the different types of received criticality information of the Procedure Code according to 
the following: 

Reject IE: 

If a message is received with a Procedure Code marked with "Reject IE" which the receiving node does not 
comprehend, the receiving node shall reject the procedure using the Error Indication procedure. 

Ignore IE and Notify Sender: 

If a message is received with a Procedure Code marked with "Ignore IE and Notify Sender" which the receiving 
node does not comprehend, the receiving node shall ignore the procedure and initiate the Error Indication 
procedure. 

Ignore IE: 

If a message is received with a Procedure Code marked with "Ignore IE" which the receiving node does not 
comprehend, the receiving node shall ignore the procedure. 

When using the Error Indication procedure to reject a procedure or to report an ignored procedure it shall include the 
Procedure Code IE, the Triggering Message IE, and the Procedure Criticality IE in the Criticality Diagnostics IE. 

4.5.3.4.2 Type of Message 

When the receiving node cannot decode the Type of Message IE, the Error Indication procedure shall be initiated with 
an appropriate cause value. 

4.5.3.4.3 lEs other than the Procedure Code and Type of Message 

The receiving node shall treat the different types of received criticality information of an IE/IE group other than the 
Procedure Code IE and Type of Message IE according to the following: 

Reject IE: 

If a message initiating a procedure is received containing one or more lEs/IE groups marked with "Reject IE" 
which the receiving node does not comprehend; none of the functional requests of the message shall be executed. 
The receiving node shall reject the procedure and report the rejection of one or more lEs/IE groups using the 
message normally used to report unsuccessful outcome of the procedure. In case the information received in the 
initiating message was insufficient to determine a value for all lEs that are required to be present in the message 
used to report the unsuccessful outcome of the procedure, the receiving node shall instead terminate the 
procedure and initiate the Error Indication procedure. 

If a message initiating a procedure that does not have a message to report unsuccessful outcome is received 
containing one or more lEs/IE groups marked with "Reject IE" which the receiving node does not comprehend, 
the receiving node shall terminate the procedure and initiate the Error Indication procedure. 

If a response message is received containing one or more lEs marked with "Reject IE" which the receiving node 
does no comprehend, the receiving node shall consider the procedure as unsuccessfully terminated and initiate 
local error handling. 
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Ignore IE and Notify Sender: 

If a message initiating a procedure is received containing one or more les/IE groups marked with "Ignore IE and 
Notify Sender" which the receiving node does not comprehend, the receiving node shall ignore the content of the 
not comprehended lEs/IE groups, continue with the procedure as if the not comprehended lEs/IE groups were 
not received (except for the reporting) using the understood lEs/IE groups, and report in the response message of 
the procedure that one or more lEs/IE groups have been ignored. In case the information received in the 
initiating message was insufficient to determine a value for all lEs that are required to be present in the response 
message, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure. 

if a message initiating a procedure that does not have a message to report the outcome of the procedure is 
received containing one or more lEs/IE groups marked with "Ignore IE and Notify Sender" which the receiving 
node does not comprehend, the receiving node shall ignore the content of the not comprehended lEs/IE groups, 
continue with the procedure as if the not comprehended lEs/IE groups were not received (except for the 
reporting) using the understood lEs/IE groups, and initiate the Error Indication procedure to report that one or 
more lEs/IE groups have been ignored. 

If a response message is received containing one or more lEs/IE groups marked with "Ignore IE and Notify 
Sender" which the receiving node does not comprehend, the receiving node shall ignore the content of the not 
comprehended IE/IE groups, continue with the procedure as if the not comprehended lEs/IE groups were not 
received (except for the reporting) using the understood lEs/IE groups and initiate the Error Indication 
procedure. 

Ignore IE: 

If a message initiating a procedure is received containing one or more lEs/IE groups marked with "Ignore IE" 
which the receiving node does not comprehend, the receiving node shall ignore the content of the not 
comprehended lEs/IE groups and continue with the procedure as if the not comprehended lEs/IE groups were 
not received using only the understood lEs/IE groups. 

If a response message is received containing one or more lEs/IE groups marked with "Ignore IE" which the 
receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended lEs/IE 
groups and continue with the procedure as if the not comprehended lEs/IE groups were not received using the 
understood lEs/IE groups. 

When reporting not comprehended lEs/IE groups marked with "Reject IE" or "Ignore IE and Notify Sender" using a 
response message defined for the procedure, the Information Element Criticality Diagnostics IE shall be included in the 
Criticality Diagnostics IE for each reported IE/IE group. 

When reporting not comprehended lEs/IE groups marked with "Reject IE" or "Ignore IE and Notify Sender" using the 
Error Indication procedure, the Procedure Code IE, the Triggering Message IE, Procedure Criticality IE, and the 
Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported 
IE/IE group. 

4.5.3.5 Missing IE or IE group 

The receiving node shall treat the missing IE/IE group according to the criticality information for the missing IE/IE 
group in the received message specified in the version of the present document used by the receiver: 

Reject IE: 

if a received message initiating a procedure is missing one or more lEs/IE groups with specified criticality 
"Reject IE"; none of the functional requests of the message shall be executed. The receiving node shall reject the 
procedure and report the missing lEs/IE groups using the message normally used to report unsuccessful outcome 
of the procedure. In case the information received in the initiating message was insufficient to determine a value 
for all lEs that are required to be present in the message used to report the unsuccessful outcome of the 
procedure, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure. 

if a received message initiating a procedure that does not have a message to report unsuccessful outcome is 
missing one or more lEs/IE groups with specified criticality "Reject IE", the receiving node shall terminate the 
procedure and initiate the Error Indication procedure. 

if a received response message is missing one or more lEs/IE groups with specified criticality "Reject IE, the 
receiving node shall consider the procedure as unsuccessfully terminated and initiate local error handling. 
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Ignore IE and Notify Sender: 

if a received message initiating a procedure is missing one or more lEs/IE groups with specified criticality 
"Ignore IE and Notify Sender", the receiving node shall ignore that those lEs are missing and continue with the 
procedure based on the other lEs/IE groups present in the message and report in the response message of the 
procedure that one or more lEs/IE groups were missing. In case the information received in the initiating 
message was insufficient to determine a value for all lEs that are required to be present in the response message, 
the receiving node shall instead terminate the procedure and initiate the Error Indication procedure. 

if a received message initiating a procedure that does not have a message to report the outcome of the procedure 
is missing one or more lEs/IE groups with specified criticality "Ignore IE and Notify Sender", the receiving node 
shall ignore that those lEs are missing and continue with the procedure based on the other lEs/IE groups present 
in the message and initiate the Error Indication procedure to report that one or more lEs/IE groups were missing. 

if a received response message is missing one or more lEs/IE groups with specified criticality "Ignore IE and 
Notify Sender", the receiving node shall ignore that those lEs are missing and continue with the procedure based 
on the other lEs/IE groups present in the message and initiate the Error Indication procedure to report that one or 
more lEs/IE groups were missing. 

Ignore IE: 

if a received message initiating a procedure is missing one or more lEs/IE groups with specified criticality 
"Ignore IE", the receiving node shall ignore that those lEs are missing and continue with the procedure based on 
the other lEs/IE groups present in the message. 

if a received response message is missing one or more lEs/IE groups with specified criticality "Ignore IE", the 
receiving node shall ignore that those lEs/IE groups are missing and continue with the procedure based on the 
other lEs/IE groups present in the message. 

When reporting missing lEs/IE groups with specified criticality "Reject IE" or "Ignore IE and Notify Sender" using a 
response message defined for the procedure, the Information Element Criticality Diagnostics IE shall be included in the 
Criticality Diagnostics IE for each reported IE/IE group. 

When reporting missing lEs/IE groups with specified criticality "Reject IE" or "Ignore IE and Notify' Sender" using the 
Error Indication procedure, the Procedure Code IE, the Triggering Message IE, Procedure Criticality IE, and the 
Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported 
IE/IE group. 

4.5.3.6 lEs or IE groups received in wrong order or witin too many 
occurrences or erroneously present 

If a message with lEs or IE groups in wrong order or with too many occurrences is received or if lEs or IE groups with 
a conditional presence are present when the condition is not met (i.e. erroneously present), the receiving node shall 
behave according to the following: 

If a message initiating a procedure is received containing lEs or IE groups in wrong order or with too many 
occurrences or erroneously present, none of the functional requests of the message shall be executed. The 
receiving node shall reject the procedure and report the cause value "Abstract Syntax Error (Falsely Constructed 
Message)" using the message normally used to report unsuccessful outcome of the procedure. In case the 
information received in the initiating message was insufficient to determine a value for all lEs that are required 
to be present in the message used to report the unsuccessful outcome of the procedure, the receiving node shall 
instead terminate the procedure and initiate the Error Indication procedure. 

If a message initiating a procedure that does not have a message to report unsuccessful outcome is received 
containing lEs or IE groups in wrong order or with too many occurrences or erroneously present, the receiving 
node shall terminate the procedure and initiate the Error Indication procedure, and use cause value "Abstract 
Syntax Error (Falsely Constructed Message)". 

If a response message is received containing lEs or IE groups in wrong order or with too many occurrences or 
erroneously present, the receiving node shall consider the procedure as unsuccessfully terminated and initiate 
local error handling. 
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When determining the correct order only the lEs specified in the specification version used by the receiver shall be 
considered. 



4.5.4 Logical Error 



Logical error situations occur when a message is comprehended correctly, but the information contained within the 
message is not valid (i.e. semantic error), or describes a procedure which is not compatible with the state of the receiver. 
In these conditions, the following behaviour shall be performed (unless otherwise specified) as defined by the class of 
the elementary procedure, irrespective of the criticality information of the lE's/IE groups containing the erroneous 
values. 

Class 1: 

Where the logical error occurs in a request message of a class 1 procedure, and the procedure has a message to report 
this unsuccessful outcome, this message shall be sent with an appropriate cause value. Typical cause values are: 

Semantic Error; 

Message not compatible with receiver state. 

Where the logical error is contained in a request message of a class 1 procedure, and the procedure does not have a 
message to report this unsuccessful outcome, the procedure shall be terminated and the Error Indication procedure shall 
be initiated with an appropriate cause value. The Procedure Code IE and the Triggering Message IE within the 
Criticality Diagnostics IE shall then be included in order to identify the message containing the logical error. 

Where the logical error exists in a response message of a class 1 procedure, the procedure shall be considered as 
unsuccessfully terminated and local error handling shall be initiated. 

Class 2: 

Where the logical error occurs in a message of a class 2 procedure, the procedure shall be terminated and the Error 
Indication procedure shall be initiated with an appropriate cause value. The Procedure Code IE and the Triggering 
Message IE within the Criticality Diagnostics IE shall then be included in order to identify the message containing the 
logical error. 



4.5.5 Exceptions 



The error handling for all the cases described hereafter shall take precedence over any other error handling described in 
the other subclauses of clause 4.5. 

If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is detected in the ERROR 
INDICATION message, it shall not trigger the Error Indication procedure in the receiving Node but local error 
handling. 

In case a response message or Error Indication message needs to be returned, but the information necessary to 
determine the receiver of that message is missing, the procedure shall be considered as unsuccessfully terminated 
and local error handling shall be initiated. 

If an error that terminates a procedure occurs, the returned cause value shall reflect the error that caused the 
termination of the procedure even if one or more abstract syntax errors with criticality "ignore and notify" have 
earlier occurred within the same procedure. 



£75/ 



3GPP TS 29.168 version 8.2.0 Release 8 



30 



ETSI TS 129 168 V8.2.0 (2009-10) 



Annex A (informative): 
Change history: 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


2008-12 


CT#42 


CP-080972 






VI. 0.2 approved in CT#42 


1.0.2 


8.0.0 


2009-03 CT#43 


CP-090101 
CP-090022 


0001 


3 


General clean-up to make an alignment with RAN 
specifications 


8.0.0 8.1.0 


0002 




General clean-up to make an alignment with RAN 
specifications 


2009-09 CT#45 


CP-090543 


0003 


1 


Correct ASN.l misalignment between SlAP and SB-AP 


8.1.0 8.2.0 


0004 


1 


Fix the ASN.l Object Identifiers (OID) descriptions for 
SBc-AP 


0005 


1 


Update port number and payload protocol identifier for 
SBc-AP 






0006 




Fix incorrect IETF reference 







£75/ 



3GPP TS 29.168 version 8.2.0 Release 8 



31 



ETSI TS 129 168 V8.2.0 (2009-10) 



History 



Document history 


V8.0.0 


January 2009 


Publication 


V8.1.0 


April 2009 


Publication 


V8.2.0 


Ocotber 2009 


Publication 















£75/ 



